!pr1
Feedback about the latest Sieve............Peter J. McInerney

So the Sieve lives!  Bob's article last month misses some of the facts, however.  He states that my improved 68000 version on my 12.5 MHz DTACK Grounded board ran in .4 seconds; the actual time was .33 seconds.  This is proportional to the .49 seconds claimed in the later Byte article for an 8 MHz 68000.  My DTACK Grounded board uses 120 nanosecond static RAM and runs at a full 12.5 MHz speed (DTACK grounded means that the processor CANNOT wait for memory).

Hal Hardenburgh (editor of the now sadly no more DTACK newsletter and no slouch when it comes to assembly programming on the 68000) produced his own version of the original algorithm, essentially hand-compiled BASIC since that was what he wanted to compare to, and that ran in 1.29 secs for 10 iterations on a 10MHz board.

My faster 68000 sieve was my first 68000 program, so in light of my now more extended experience I tried to tighten it up even further.  The result runs in .28 seconds for ten iterations on my DTACK board, and .72 seconds on a Macintosh.  The main speed improvement comes from loading two extra registers for comparisons rather than doing CMPI's.  The use of MOVEM for clearing the array was pointed out to me by Hal Hardenburgh and accounts for about .02 secs saved, at the expense of a large amount of elegance (oh well, what price aesthetics?).

In trying to guess the comparisons of the 65816 systems of the future with existing 68000 systems, two questions come to mind.  First, if 6 or 8 MHz 65816s become available in quantity, how fast will the memory have to be to keep up?  The 68000 can automatically adjust for slower memories, but is this true of the 65816?  Second, and more importantly, is the question of memory addressing.

I wrote a version of the sieve that sifts the first 262143 integers.  This took 13.5 seconds for 10 iterations on a Macintosh (this should equate to 5.3 seconds on my DTACK board, but I don't have enough memory to test it.)  The program is only minimally different from the original (some constants changed and some address modes changed from word to long.)

How about writing a 65816 program to handle this large of an array?  How much extra baggage is required to test page boundaries, move base addresses, etc?  My point is that the restriction of 64K banks can really hurt in accessing large data arrays.  Memory is getting cheaper all the time, so using more bytes for a 68000 program may well be no penalty, compared with the extra difficulty of writing 65816 code to handle large amounts of data.
